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DETAILED ACTION 

1 . This non-final office action is in response to the Applicant's Request for 
Continued Examination filed September 12, 2005 wherein Applicant amended claims 1- 
12, 14-27 and 30-34 and canceled claim 29 (claims 13 and 28 being previously 
canceled). Currently claims 1-12, 14-27 and 30-34 are pending. 

Response to Arguments 

2. Applicant's arguments filed September 12, 2005 with respect to pending claim 1- 
12, 14-27 and 30-34 have been considered but are moot in view of the new ground(s) of 
rejection. 

It is noted that the applicant did not challenge the Official Notice(s) cited in the 
Office Actions dated November 23, 2004 and/or April 1 1 , 2005 therefore those 
statements as presented are herein after prior art. Specifically it has been established 
that it was old and well known in the art at the time of the invention: 

- to use object-oriented programming (OOP, 00) to build business systenis; 

- to use design patterns including but not limited to composite/compound objects 
and observer patterns when building business systems; 

- the use of a plurality of methods for comparing objects (attributes, properties, 
values, etc.; invoking comparison logic) and generating results indicating differences 
from the comparison as well as that any comparison of two or more objects (orders) 
which inherently provide a mechanism for identifying the objects to be compared; 
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- to provide objects with the ability to recognize, record and signal when changes 
to the objects properties/attributes occur (e.g. observer pattern); 

- that there are a plurality of commonly used approaches (methods, techniques, 
etc.) for creating new and/or modified objects based on existing (peer) objects one such 
approach being copy-then-modify approaches including such techniques as 
deep/shallow copy; 

- to use program control structures (for, while, if-then-else, for-each, etc.) to 
iterativeiy/recursively process a set/collection of objects/information; 

- to provide a mechanism for capturing the evolution of an object or transaction, 
more specifically to capture snapshots of the item before and after modifications are 
made or transactions take place; 

- that when peri'orming a series of operations whose ultimate goal is to produce a 
result (document, numerical value, method call, etc..) to either generate that result 
concurrent with the performance of each iterative step or after all the steps have been 
completed; 

- that Electronic Data Interchange (EDI) standard supports the order 
management process specifically the creation of purchase orders and the handling of 
purchase change orders; 

- that EDI provides for the inter-organizational electronic exchange of business 
documents in a structured, machine-processable format; i.e. EDI provides a "language" 
specially designed for the processing, definition and presentation of text (markup 
language); and 
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- that at either end of an EDI transaction is a translation component which 
converts the standard EDI format for the transaction into the business specific format 
necessary for completion of the transaction thereby enabling companies to transact in a 
common "language" (text, markup, format, etc.). 

Title 

3. The title of the invention is not descriptive. A new title is required that is clearly 
indicative of the invention to which the claims are directed. 

The following title is suggested: Method and System for Processing Changes To 
Existing Purchase Orders in an Object-Oriented Order Processing System. 
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Claim Rejections - 35 USC § 102 

4. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

5. Claims 1, 14-15, 30 and 32-33 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Marcam Solutions, Inc., WO 99/57664 (Marcam, November 1999). 

Regarding Claims 1, 14-15, 30 and 32-33 Marcam teaches an automated 
order/transaction processing system and method comprising customer purchase orders 
objects; an event generator for identifying and indicating/signaling changes to the order 
objects; action servers for executing the events; an order database and a user interface 
or other "change-effecting" application/program/system (Abstract; Page 2, Last 
Paragraph; Page 3, Paragraph 1; "...each transaction is represented by a set of objects 
including an order object...", Paragraph 2, Page 4; Paragraph 3, Page 4; Pages 44-45; 
Figure 1, Element 16; Figures 1-3, 15). 

More specifically Marcam teaches a method and system for processing changes 
to purchase orders (orders of items for sales) in an object-oriented order processing 
(management) system comprising: 

- receiving a change (update, revisions, modification, change request, etc.) to an 
existing order (order object containing references/links to a collection/set of objects, 
compound/composite object, identity of an existing order - order ID) as a result of a 
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customer request "...were the sales representative to update the quantities of goods 
specified in the order, the event generator could generate an event object that would 
result in an action for updating the delivery price. Processing of that action may result in 
new cascaded events.", Paragraph 1, Page 4; Paragraphs 3-4, Page 4; Paragraphs 2-4; 
Page 45; Figure 1, Element 16; Pages 71; Pages 114-116; "Category of Events", 
"Attribute Value Change", Page 119); 

- generating a change order/request (action, event), containing the change, 
based on the existing purchase order (Pages 47-48; Last Paragraph, Page 50; 
Paragraphs 1-3, Pages 51, 71, 76-78; 114-116); 

- generating a result (output, data, information, etc.) indicating the differences 
(changes, revisions, updates, etc.) to the original/existing purchase order by comparing 
the change request/change order (order changes) to the existing purchase order ("An 
Order Pricing Example", Pages 76-78, 114-115; Figure 7); 

- determining if any attributes in the existing purchase order are changed 
(impacted, effected, etc.) by the change request/order and if any attributes are effected 
then indicating the differences/changes to those attributes in the change order 
(triggering condition/event/object; Last Paragraph, Page 53; Paragraphs 1-2, Page 54; ; 
Page 55; "An Order Pricing Example", Pages 76-78, 114-116; Figures 5, 7); 

- providing (outputting, displaying, sending, etc.) the change order result to a 
customer such that the customer is able to distinguish (recognize, determine, view, etc.) 
the differences between the existing order and the changed purchase order ("An Order 
Pricing Example", Pages 76-78, 103, 114-116; Figures 5, 7, 15). 
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Marcam further teaches that the order processing system and method comprises 
a memory for storing the plurality of order information (objects, parameters, etc.), a 
processor for executing/processing the orders/change requests and interfaces between 
the memory and the processor (update server; Page 44, 71-73; Figures 1-3). 
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For instance the event set generated during the maintenance of the following 



delivery 



Order !23. Line 1, Delivery 1 
Attribute Was Change 
Quantity 100 90 
Ship-To Trading Partner 

00 i 003 
Deliveiy Priority 

5 3 



Event 

DelivcTy Quantity Updated (minor) 

Ship-To Trading Partner Updated (minor) 

Delivery Priority Updated (minor) 
Delivery Maintained (major) 



Figure 1: Screen Shot Page 115 
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Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

7. Claims 2-12, 16-27, 31 and 34 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Marcam Solutions, Inc., WO 99/57664 (Marcam, November 1999) as 
applied to claims 1, 14-15, 30 and 32-33 above and further in view of official notice. 

Regarding Claims 2 and 16 Marcam teaches a ordering processing system and 
method wherein generating a change order further comprises: 

- using the existing order (object) to create a changed order (object) such that 
the changed/updated order (object) contains any objects/parameters/attributes 
contained within the existing order and has at least one attribute and an associated 
value (Pages 76-78; 114-116; "Category of Events", "Attribute Value Change", Page 
119; Figures 1-4); and 

- updating/changing (replacing (setting, revising, etc.) the changed attributes 
(change request,, order changes, etc.) in the changed order object (i.e. replace the 
original values with the new values) while not changing/updating the original/existing 
purchase order (Pages 3-4, 45, 71 , 76-78; 1 14-116). 
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Marcam does not expressly teach creating a changed purchase order by copying 
the existing purctiase order to a change order object such that the change order object 
contains any objects/parameters/attributes contained within the existing order as 
claimed. 

Official notice is taken that it is old and very well known in the art at the time of 
the invention, as cited in the previous office actions that there are a plurality approaches 
to creating new (modified version of existing objects) objects based on existing objects 
including but not limited to the use of deep copy, constructs a new compound object 
and then, recursively, inserts copies of the nested objects found in the original 
compound object into the new compound object, and shallow copy, constructs a new 
compound object and then inserts the same objects into in new object that are 
contained the original contains. These copy-then-modify techniques ensure that only 
the minimum amount of time is spent in creating a modified version of the original object 
(by only changing the modified values, instead of copying the values one at a time) and 
ensure that any complex relationships or attributes associated with the original object 
are carried over to the new modified version of the object. 

It would have been obvious to one skilled in the art at the time of the invention 
that the order processing system and method for processing changes to orders as 
taught by Marcam would have benefited from and used a plurality of object-oriented 
techniques and/or design patterns for generating change orders including but not limited 
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to creating change orders by copying the original/existing purchase order (object) and 
then modifying only the purchase order object attributes (values, properties, nested 
objects, etc.) as indicated by the customer requested changes in view of the teachings 
of official notice; the resultant system ensuring that any complex relationships and/or 
attributes associated with the original purchase order (object) are "carried over" to the 
new modified version of the purchase order (changed order, object). 

Regarding Claims 3 and 17 Marcam teaches an order processing system and 
method wherein receiving a change order (change request) further comprises: 

- receiving an identification of an existing purchase order (e.g. order ID) that is to 
be changed/updated (arguments; Paragraph 3, Page 45; Pages 114-116, 137; Figures 
1-4); 

- placing a hold (pause, suspend, lock, etc.) on the existing purchase order 
(Pages 6, 71, 110, 116); 

- receiving the new value(s) (change requests, etc.; "Methods contained in the 
order object 16, detect changes to the information contained in it. Those methods 
signal events whenever changes occur that require computational processing (e.g. 
changes that affect order pricing), that impact order handling (e.g. changes to shipping 
address), or that are otherwise substantive in nature.". Paragraph 4, Page 45; Pages 3- 
4, 76-78; 114-116; Figure 1); and 

- wherein generating the change order based on the existing purchase order 
further comprises for each object in the existing purchase order for which there is a new 
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value by assigning the new value to the corresponding attribute (Pages 76-68; 1 14-1 16; 
Figures 1-4). 

Marcam does not expressly teach generating a change order by copying the 
existing/original purchase order object attributes (properties, parameters, nested 
objects, values, etc.) as claimed. 

Official notice is taken that it is old and very well known in software engineering, 
as cited in the previous office actions, that there are a plurality of well known 
approaches for creating new (modified version of existing objects) objects based on 
existing objects including but not limited to the use of deep copy and shallow copy as 
discussed above. These copy-then-modify techniques ensure that only the minimum 
amount of time is spent in creating a modified version of the original object (by only 
changing the modified values, instead of copying the values one at a time) and ensure 
that any complex relationships or attributes associated with the original object are 
carried over to the new modified version of the object. 

It would have been obvious to one skilled in the art at the time of the invention 
that the order processing system and method for processing changes to orders as 
taught by Marcam would have benefited from and used a plurality of object-oriented 
techniques and/or design patterns for generating change orders including but not limited 
to creating change orders by copying the original/existing purchase order (object) and 
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then modifying only the purchase order object attributes (values, properties, nested 
objects, etc.) as indicated by the customer requested changes in view of the teachings 
of official notice; the resultant system ensuring that any complex relationships and/or 
attributes associated with the original purchase order (object) are "carried over" to the 
new modified version of the purchase order (changed order, object). 

Regarding Claims 4, 7-8, 18 and 21-22 Marcam teaches an order processing 
method and system wherein comparing the change order to the existing purchase order 
further comprises for each object in the existing/original purchase order object for which 
there is a new/updated value generating a change order result that identifies the new 
and original/existing values (i.e. providing the existing value/change order result for 
each of the multiple objects (parameters, values, line items, etc.) contained in the 
existing order for which the change order/request object indicates a new value or for 
each object (parameter, attribute) in the existing purchase order that has a different 
(new, updated, revised, etc.) value indicating (identifying, providing, displaying, 
outputting, etc.) the value of the object in the change order and the existing value of the 
object; "Methods contained in the order object 16, detect changes to the information 
contained in it. Those methods signal events whenever changes occur that require 
computational processing (e.g. changes that affect order pricing), that impact order 
handing (e.g. changes to shipping address), or that are otherwise substantive in 
nature.". Paragraph 4, Page 45; "A minor event not only tells us that there has been 
some state change on the target object but also gives us an indication of what attribute 
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has been updated.", Paragraph 1, Page 115; "Category of Events", "Attribute Value 
Change", Page 119; Pages 55, 114-116, 137). 

Regarding Claims 5 and 19 Marcam teaches an order processing system and 
method wherein the comparing of the change request/order and the existing order is 
done concurrently with the step of generating the change order (synchronously, 
immediately, instantaneously, etc.; "immediate event processor"; Paragraphs 3-4, Page 
46; Pages 47, 55; Figures 2-3). 

Regarding Claims 6 and 20 Marcam teaches an order processing system and 
method wherein the comparing of the change request/order and the existing order is 
done after the steps of generating a change order/request (delayed, asynchronously; 
Paragraphs 3-4, Page 46; Pages 47-48, 55; Figures 2-3, 5). 

Regarding Claims 9 and 23 Marcam teaches an order processing system and 
method wherein the change order result is formatted using at least one of text and a 
markup language (EDI; Page 71; GUI; Pages 114-116; Figures 15-20) 

Regarding Claims 10 and 24-25 Marcam does not expressly teach that the 
change order result is provided in a text/markup language format based on an identity of 
a recipient as claimed. 
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Official notice is taken that providing (displaying, sending, outputting, etc.) 
message (a text/markup language) in a format based on an identity (role, system type, 
standard, etc.) of a recipient (system, user, etc.) is old and very well known, as cited in 
the previous office actions. 

Specifically it is old and well known in the art that EDI provides for the inter- 
organizational electronic exchange of business documents in a structured, machine- 
process able format. EDI standards permit direct computer-to-computer exchange of 
formatted business transactions between business partners and makes it possible for 
organizations to generate, receive and process large volumes of information, swiftly and 
with limited human intervention. EDI provides a "language" specially designed for the 
processing, definition and presentation of text (markup language). 

Further it is well known that at either end of an EDI transaction is a translation 
component which converts the standard EDI format for the transaction into the business 
specific format necessary for completion of the transaction thereby enabling companies 
to transact in a common "language" without having to convert all their existing legacy 
systems to the common language thereby saving time, effort and money. 

It would have been obvious to one skilled in the art at the time of the invention 
that the collaborative order management system as taught by Marcam would have 
benefited from generating the change order result in any of a plurality of formats 
including EDI messages and/or XML documents in view of the teachings of official 
notice; the resultant system supporting each businesses (trading partners) "unique" 
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message format (language) thereby facilitating the participation of multiple business in a 
supply chain. 

Regarding Claims 11, 26, 31 and 34 Marcam teaches an object-oriented order 
processing system and method for processing change orders/request comprising: 

- receiving, from a customer (user, consumer, purchaser, etc.), a new value for 
an attribute (parameter, object, property, etc.) in an existing/original purchase order (i.e. 
change order, change request) wherein the purchase order is represented as an 
compound/composite object (Pages 114-116; Figures 1-4; "Category of Events", 
"Attribute Value Change", Page 119); 

- using the existing purchase order to create a changed/updated order based on 
the original/existing order wherein the changed order contains the changed 
value/parameter/object and a reference (link, method, attribute) to a comparator object 
(order comparator object, logic, subroutine, code, module, etc.; Pages 76-78, 114-115; 
Figures 1-4); 

- assigning the new value to the corresponding (peer) change order object 
parameter/property/object ("An Order Pricing Example", Pages 76-78; Pages 114-116); 

- indicating (providing, displaying, outputting, etc.) to the customer the 
differences between the original/existing purchase order and the change order (change 
request, updated order, etc.) by comparing (comparison login) the two order objects and 
determining if any attributes (values, parameters) have changed based on the change 
order/request so that the customer can distinguish the differences between the 
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existing/original purchase order and the changed/updated/revised purchase order ("An 
Order Pricing Example", Pages 76-78; Page 115; Figure 15-20). 

Marcam does not expressly teach creating a change order object by copying an 
existing purchase order to a change order as claimed. 

Official notice is taken that it is old and very well known in software engineering, 
as cited in the previous office actions, that there are a plurality of well known 
approaches for creating new (modified version of existing objects) objects based on 
existing objects including but not limited to the use of deep copy and shallow copy as 
discussed above. These copy-then-modify techniques ensure that only the minimum 
amount of time is spent in creating a modified version of the original object (by only 
changing the modified values, instead of copying the values one at a time) and ensure 
that any complex relationships or attributes associated with the original object are 
carried over to the new modified version of the object. 

It would have been obvious to one skilled in the art at the time of the invention 
that the order processing system and method for processing changes to orders as 
taught by Marcam would have benefited from and used a plurality of object-oriented 
techniques and/or design patterns for generating change orders including but not limited 
to creating change orders by copying the original/existing purchase order (object) and 
then modifying only the purchase order object attributes (values, properties, nested 
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objects, etc.) as indicated by the customer requested changes in view of the teachings 
of official notice; the resultant system ensuring that any complex relationships and/or 
attributes associated with the original purchase order (object) are "carried over" to the 
new modified version of the purchase order (changed order, object). 

Regarding Claims 12 and 27 Marcam teaches an order processing system and 
method wherein the comparison logic (comparison of the two orders) further comprises: 

- receiving an identity (handle) of the existing/original purchase order (peer 
object; e.g. order ID, arguments; Paragraph 3, Page 45; Pages 114-116, 137; Figures 
1-4) and changed/updated purchase order/request; and 

- generating a change order result indicating the existing purchase order values 
and the updated/revised purchase order values by comparing an existing value from the 
existing/original purchase order to the new value in the change request/order (Pages 
76-78,114-116). 
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Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

- Doyle et al., U.S. Patent No. 5,694,551, teach an order processing system and 
method wherein users of the system are provided with the ability to create, change and 
cancel/delete pending (on hold, paused, suspended, etc.) and active customer orders 
stored in a database. 

- Wiecha, Charles Francis, U.S. Patent No. 5,870,717, teaches an order 
processing system and method that supports changes (change requests, order 
cancellations; e.g. add/delete line items, requested ship date, etc.), received from 
customers, to purchase orders and shopping carts (product clip board) through the 
implementation of well-known EDI standards (e.g. EDI 850/860). Wiecha further 
teaches that users can cancel orders if they have not been shipped and that the 
changes are recorded/logged for reporting purposes. 

- Barnes et al., U.S. Patent No. 5,970,475, teach a purchase order processing 
system and method wherein the system implements/supports well known EDI standards 
for creating and changing/updating purchase orders (EDI 850, 860, 865). Barnes et al. 
further teaches that purchase order change requests indicate the line item (multiple 
objects in the purchase order) changes including such changes as additions, deletions 
or amended quantities and that the total of the purchase order will be updated to reflect 
the updates/changes as well as the items not changed. Barnes et al. further teach that 
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the order processing system utilizes a third-party EDI translator to transform 
messages/system communications into and out of well known EDI formatted messages. 

- Arnold et al., U.S. Patent No. 5,987,423, teach an object-oriented order (sales 
order, purchase order) processing system and method wherein the system supports 
generating new orders as well as updating existing/previous orders and further wherein 
orders are represented as multiple objects (order object has references to other objects 
that makeup the order). 

- Blinn et al., U.S. Patent No. 6,058,373, teach an Internet-based object-oriented 
order processing system and method. 

- Leonard, Timothy J., U.S. Patent no. 6,085,171, teaches an order processing 
system and method for processing changes to customer orders wherein the system 
receives change orders/requests from customer to change existing orders/services. 
Leonard further teaches that orders can be placed into a plurality of states including 
being placed on hold during the order processing process. 

- Krueger et al., U.S. Patent No. 6,868,387, teach an order processing system 
and method wherein changes to purchase order items (e.g. line items, parts, etc.) 
triggers the identification and subsequent updating of purchase orders containing the 
updated order items. 

- Gosko, Theresa M., U.S. Patent No. 6,871,187, teaches a system and method 
for translating/transforming/mapping order processing related communications between 
customer/supplier/manufacturer systems enabling systems to communicate despite 
having different communication formats. 
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- Borders et al., U.S. Patent Publication No. 2001/0047285, teach an Internet- 
based order processing system and method wherein the system/method processes new 
and updated orders (order data). 

- Chehade et al., U.S. Patent Publication No. 2002/0128946, teach a system and 
method for supporting business processes utilizing the well known RosettaNet standard, 
specifically RosettaNet's support for managing purchase orders and purchase order 
change requests. Chehade et al. further teach that the system and method for 
supporting business processes provides message translation in order to 
convert/transform messages into and out of required/specified formats. 

- RosettaNet PIP3A4: Manage Purchase Order (2000) teaches a well-known 
standard/process definition that "specify the purchase order management process 
between trading partners. The management process includes the creation, change and 
cancellation Business Document." and further wherein business partners communicate 
via defined XML messages. The article further teaches that the RosettaNet 
specification covers purchase requests comprising of two basic types: "1. The original 
purchase order request with the content changed." or "2. A new change request that 
only contains changes to the original purchase order." 
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Figure 4-1 specifies the network conrponents and their message exchange. 
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- RosettaNet PIP3B5: Request Shipment Change (2000), teaches a well known 
standard for supporting business processes wherein one of the supported business 
processes includes purchase order management and more specifically the process by 
which customers can request changes to existing purchase orders (e.g. shipment 
change while order is in transit) and suppliers/vendors can process (accept/reject) those 
change order requests. 

- RosettaNet PIP3A8: Request Purchase Order Change (2001) teaches a well 
known standard the defines a plurality of business processes in a supply chain, 
specifically the process for supporting purchase order changes as art of an order 
management/processing process. The article further teaches that the standard 
"enables a buyer to change purchase order line items and obtain a quick response from 
the provider that acknowledges, at the line level, if the changes are accepted, rejected 
or pending." 

- McKie, Stewart, Understanding business objects (1995) teaches the well 
known utilization of object-oriented programming (00, OOP) for designing and 
implementing a plurality of business systems including but not limited to object-oriented 
order processing systems wherein purchase orders are represented as 
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composite/compound objects. McKie further teaches that all business objects (e.g. 
purchase order objects) have lifecycles wherein changes/updates to the object trigger 
events that "...effect the object itself or those connected to it...." 

- Coonnbs, Jason et al., Order Processing on Your E-Commerce Site, teach an 
Internet-based object-oriented order processing system and method wherein users can 
return to purchase orders (shopping carts) that are put on hold/suspended/not- 
completed in order to update/revise the purchase orders and that upon the updating of 
the purchase order the system determines (re-calculates) the effect of the changes in 
the purchase order or the system have on the purchase order (e.g. a price for a line- 
item in the purchase order has changed since the purchase order was last updated). 
Coombs et al. further teaches that the system enables users to make changes to 
existing orders. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Scott L. Jarrett whose telephone number is (571) 272- 
7033. The examiner can normally be reached on Monday-Friday, 8:00AM - 5:00PM. 

if attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hafiz Tariq can be reached on (571) 272-6729. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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